95장. 배포 자동화 — CodePipeline · CodeDeploy

이 장에서 말하고자 하는 것

빌드된 이미지를 ECS Service로 올리고
인프라 변경을 적용하는 일까지가 배포(CD) 다.

• 새 이미지가 ECR에 올라오면 자동으로 stage로 → prod로
• 인프라 변경이 머지되면 자동으로 적용
• 사람이 손대지 않고 검증된 흐름

AWS의 두 가지 핵심 도구:

• AWS CodePipeline — 단계(Stage) 를 묶는 파이프라인
• AWS CodeDeploy — 배포 전략 실행 (Rolling · Blue-Green · Canary)

그리고 GitHub Actions / Argo CD 같은 외부 도구도 자연스럽게 쓰인다.

1. CI vs CD vs IaC 배포

CI (94장)  : 코드 → 이미지
CD (이 장) : 이미지 → ECS Service
IaC 배포   : Terraform → 인프라 변경

운영 자동화는 셋이 함께 굴러간다.

2. CodePipeline — 단계의 묶음

Source        → S3 / GitHub / CodeCommit
Build         → CodeBuild
Deploy (Stage) → CodeDeploy / ECS Service / S3 동기화
Approval      → 사람이 클릭 (선택)
Deploy (Prod) → CodeDeploy ...

각 Stage 사이에 Approval 을 끼우면 “stage 검증 후 사람이 prod 클릭” 흐름.

3. CodeDeploy — 배포 전략의 실행

ECS와 묶여 Blue-Green 배포를 제공.

새 Task Definition 등록
  ↓
Green TG에 새 버전 띄움
  ↓
헬스 체크 통과
  ↓
ALB Listener 전환 (즉시 또는 Canary 비율 조정)
  ↓
일정 시간 모니터링
  ↓
문제 없음 → Blue 정리
문제 발견 → 자동 롤백

49장에서 본 Blue-Green / Canary 가 여기서 실행된다.

4. ECS Rolling vs CodeDeploy Blue-Green

단순 서비스: ECS Rolling
중요 서비스: CodeDeploy Blue-Green

5. GitHub Actions 직접 배포 — 가벼운 패턴

복잡한 CodePipeline 없이 GitHub Actions가 직접 ECS를 업데이트하는 패턴도 흔하다.

push → build → ecr push → aws ecs update-service

• 작은 ~ 중간 규모에 적합
• 외부 시스템 (Slack 알림 · 승인) 통합이 자유로움

6. Argo CD / Flux — GitOps

Kubernetes(EKS) 환경에서 자주 쓰는 패턴.

Git에 매니페스트 (k8s YAML)
  ↓ Argo CD 가 주기적으로 비교
실제 클러스터와 차이가 있으면 자동 동기화

• Git이 단일 진실
• 변경 추적 · 롤백이 git 명령
• ECS에서는 GitOps 비슷한 도구가 적지만 Terraform + GitHub Actions 조합이 비슷한 효과

7. IaC 배포 — Terraform 자동화

PR 생성
  ↓ CI: terraform plan → PR에 코멘트
사람이 plan 결과 리뷰
  ↓ 머지
CI: terraform apply (prod 환경)

• Apply 권한은 CI Role에만
• 사람 직접 apply 금지
• PR을 통한 변경만 운영에 반영

8. 우리 서비스에서

애플리케이션 배포:
  GitHub Actions (CI)
    ├─ build → ECR
    ├─ stage 자동 배포 (ECS Rolling)
    ├─ E2E 테스트
    ├─ Slack 알림 + 사람 승인
    └─ prod 배포 (ECS Rolling 또는 Blue-Green)

인프라 배포 (Terraform):
  PR → plan in CI → 리뷰 → 머지 → CI apply

데이터 마이그레이션:
  별도 Job으로 분리 (Flyway / Liquibase)
  애플리케이션 배포 직전에 자동 실행

• 핵심 서비스만 Blue-Green
• 나머지는 Rolling + 빠른 롤백

9. 직접 확인해보기 — CLI

ECS Rolling 배포

aws ecs update-service \
  --cluster msa \
  --service orders \
  --force-new-deployment

Task Definition 만 갱신 (이미지 태그만 바꿀 때)

aws ecs register-task-definition --cli-input-json file://task-def.json
aws ecs update-service \
  --cluster msa \
  --service orders \
  --task-definition orders:42

CodeDeploy Blue-Green 배포 트리거

aws deploy create-deployment \
  --application-name orders-app \
  --deployment-group-name orders-dg \
  --revision '{"revisionType":"AppSpecContent","appSpecContent":{"content":"..."}}'

10. 코드로는 이렇게 생겼다 — GitHub Actions (Rolling 배포)

name: orders-deploy

on:
  push:
    branches: [main]
    paths: ['services/orders/**']

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/GitHubDeployRole
          aws-region: ap-northeast-2

      - uses: aws-actions/amazon-ecr-login@v2

      - name: Build & Push
        run: |
          docker build -t $ECR/orders:sha-${{ github.sha }} services/orders
          docker push $ECR/orders:sha-${{ github.sha }}

      - name: Render task def
        id: td
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: task-def.json
          container-name: app
          image: ${{ env.ECR }}/orders:sha-${{ github.sha }}

      - name: Deploy
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.td.outputs.task-definition }}
          service: orders
          cluster: msa
          wait-for-service-stability: true

wait-for-service-stability: true 가 배포 완료까지 기다리게 한다 — 실패 시 워크플로우도 실패.

11. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. prod 배포에 승인 단계가 없다

의도하지 않은 변경이 그대로 흘러간다.

적어도 stage → prod 사이에 사람의 명시적 승인

안티패턴 2. 롤백 절차를 모른다

“이전 Task Definition 리비전 지정” 한 줄을 외워둔다.

안티패턴 3. DB 마이그레이션과 코드 배포가 같은 트랜잭션

실패 시 한쪽만 롤백되어 정합성이 깨진다.

마이그레이션은 두 단계 (호환 추가 → 코드 반영 → 옛 컬럼 제거)

안티패턴 4. 배포 직후 메트릭을 안 본다

새 버전이 5xx 100% 인데 모른다.

자동 롤백 + 사람 모니터링 둘 다

12. 한 줄로 정리

배포 자동화는 빌드 → 검증 → 배포 → 모니터링 의 흐름이며,
사람의 승인 · 자동 롤백 · 추적 가능성이 운영의 토대다

13. 이 장의 핵심 정리

1. CI는 빌드, CD는 배포, IaC apply는 인프라 변경 — 셋이 함께 굴러간다.
2. CodePipeline + CodeDeploy 가 AWS 네이티브 풀스택.
3. GitHub Actions 직접 배포도 작은~중간 규모에 충분하다.
4. ECS Rolling이 기본, 중요 서비스는 CodeDeploy Blue-Green.
5. 인프라는 PR 기반 — Plan 리뷰 후 머지 시 자동 Apply.
6. DB 마이그레이션은 코드 배포와 단계를 나눠 호환성을 지킨다.